◀ Prev · Parts · Full · Next ▶

The java.util.concurrent packages' solution to the concurrent modification problem, the convoy problem, the predictable latency problem, and the multi-core problem includes an architectural choice called weak consistency. This choice means that reads like get(java.lang.Object) will not block even when updates are in progress, and it is allowable even for updates to overlap with themselves and with reads. Weak consistency allows, for example, the contents of a ConcurrentMap to change during an iteration of it by a single Thread.cite-ref-footnotegoetzpeierlsblochbowbeer200685-86-5-21-concurrenthashmap-7-0[7] The Iterators are designed to be used by one Thread at a time. So, for example, a Map containing two entries that are inter-dependent may be seen in an inconsistent way by a reader Thread during modification by another Thread. An update that is supposed to change the key of an Entry (k1,v) to an Entry (k2,v) atomically would need to do a remove(k1) and then a put(k2, v), while an iteration might miss the entry or see it in two places. Retrievals return the value for a given key that reflects the latest previous completed update for that key. Thus there is a 'happens-before' relation.

◀ Prev · Parts · Full · Next ▶